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FOPEWORD 



The Database AcMinistrator User's Guide was vnritten to aid the Database 
Administrator in determining vdiat resources are available, how Prime's 
IBMS is structured and the methods by which a database can be created 
and maintained. This User's Guide serves three purposes: 

1. to describe Prime's I^MS product for the prospective user, 

2. to describe the Database Administrator's Camiand Processor, and 

3. to provide instructions on database maintenance. 

DOCUMeWATION EXCELLENCE 

Prime is striving to maintain the highest documentation standards. To 
achieve this goal, the Database documentation will be published in 
three docimentation releases as described in section 1. This is the 
Initial Documentation Release. Prime asks that each serious Database 
user correspond his conments about this manual concerning technical 
accuracy and additional information needed to implement the task of 
Database Administrator. 



Robert E. Dawes, Technical Writer 
Technical Publications Department 
Prime Ccanputer Inc. 
145 Pennsylvania Avenue, 
Framingham, Ma. 01701 



9 July 1977 



ACKNOWLEDGEMENT 



Prime Computer, Inc. wishes to formally acknowledge the work of the 
CODASYL Programming Language Comnittee (PLC) and the Data Description 
Language Committee (DDLC) . The Data Base Task Group (DBTG) of the PLC 
produced in April, 1971 a report containing the specifications of a 
standardized data base management facility consisting of a Data 
Description Language for describing a database, a Data Description 
Language for describing that part of the database known to a OBOL 
program, and a Data Manipulation Language for COBOL. 

Ihe Prime raMS, portions of which are described in this manual, is 
based almost completely on the April 1971 DBTG specifications. Prime 
Computer is also participating in the ongoing work of OCDASYL in the 
area of data base managonent through its membership on the EDLC and on 
the Data Ease Language Task Group (DBLTG) of PLC. 



PEV. i - 10 



IDP.3043 INTPODUCTICN 

SECTION 1 
INTRCOUCTIOJ 



ABOUT THIS MANUAL 

Ihis manual is oriented toward knowledgeable Database Management Syston 
(DBMS) personnel (i.e., the potential Database Administrator or 
consulting expert) in Data Managonent. Eeaders are invited to make a 
direct comparison of the functional capabilities provided with the 
DBTG-71 specification. 

The reader is assuned to be acquainted with the basic concepts of 
Virtual Msnory Operating ^stons; he should also be intimately 
familiar with Data Managanent in goieral, the benefits of Database 
Managenent in particular, the DEIG-71 Report, and relevant Prime 
product bulletins. 



PRIME raMS DOCIMENTATICN 

DBMS docunentation (Figure 1-1) is provided for both the Database 
Administrator and the application prograimter. The Database 
Administrator uses two manuals: 1) The Prime Database Administator 
User's Guide and 2) Itie Prime DBMS SCHEMA Data Description Language 
(DDL) REFERENCE Manual. 

Ihe application programmer uses two manuals per application language: 
1) the Prime FORTRAN Reference Manual for EBMS and the ccaipanion Prime 
FORTRAN User's Guide; 2) The Prime COBOL Reference Manuals for DBMS 
and the conpanion Prime COB<X User's Guide. 

The Prime E»MS SCHEMA DDL Reference Manual contains definitions and 
rules for using the WL syntax and "How to Use" procedures for the 
Schema DDL Canpiler. 

The amplication programmer uses the COBCX and FORTRAN Reference Manuals 
for IBMS for syntax definition and rules and "How to Use" procedures 
for the Subschema K)L Compilers and DML Preprocessors. 
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Figure 1-1. PRIME DBMS Docuaiientation 
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Documentation Releases 

Prime provides three docimentation relea^s (see Figure 1-2) for every 
new product: Itie Initial Documentation Release (IDR) , the Preliminary 
Docianentation Release (PDR) , and the Final Docimentation Release (FDR) . 

The Initial Documentation Release (IDR) provides advanced information. 
The intent is to provide usable, accurate information without regard to 
style and format. 

The Preliminary Documentation Release (PDR) is the second draft by the 
writer. It provides more conplete and accurate information about the 
product, but does not represent the final document format. 

The Final Documentation Release (FDR) is the complete product 
description up to the stated software revision number. This Release is 
edited, formatted and presented in Prime's highest professional 
standards. Users will be notified vdien this release is available. 



OTHER RELATED PRIME DCTIMENTS 

O PRIMOS FILE SYSTEM USER GUIDE (MAN2604) 

O PRIMCS INTERACTIVE IBER OJIDE (MAN2602) 

O PRIMCS CCMPUTER ROOM IBER (3JIDE (MAN2603) 

O PROGRAM DEVELOPMENT SOFTWARE USER GUIDE (MAN18790) 

O FORTRAN IV USER'S GUIDE (MAN3057) 

O OOB(X USER'S GUIDE (MAN2797) 
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Figure 1-2. Database Docunnentation Releases 
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LIST OF D»!S REFERENCE DOCIMENTS 

•fliis document is written assuming that the reader has a certain level 
of knowledge concerning the concepts and environment relevant to the 
Prime DBMS. To define the prerequisite level of understanding, the 
following list of docunents serves as a reference. The required 
reading list includes sane information on the PRIMC6 syston as well as 
the n COJASYL (DBTG-71) report. 

Required Reading: 

1. CCDASYL Database Task Group April 1971 Report (DBTG-71) 

2. "PRIMOS IV AND V", Prime Product Bulletin 

3. "Database Managennent System (DBMS)", Prime Product Bulletin 
Suggested Reading: 

1. HBflS Concepts: (either of the following, or equivalent) 

"Database Systens: A Practical Reference" - Ian Palmer 
^D Information Sciences 
Wellesley, Mass. 1975 

"An Introduction to Database Systems" - C. J. Date. 
Addison-Wesley, Reading, Mass., 1975 

"Canputer Database CSrganization" - James Martin. 
Prentice Hall, Englewood Qiffs, N.J., 1975 

2. Balanced Trees and B-Tree Variations: Set implementation 
Technique 

"Sorting and Searching" - D. E. Knuth 

"Ihe Art of Ocxnputer Programming, volume III" 

Addison-Wesley, Reading, Mass., 1975 

3. CODASYL Systems: 

CCDASYL Database 
Management Systons, 
ACM Computing Surveys 
Vol. 8, No. 1, March 1976 
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SECTION 2 
PRIME'S E^IS ENVIRONMENT 



INTRCDUCTION 

This section focuses on the contribution of the environment provided by 
the Prime hardware and PRIMOS software to the achievonent of the design 
objectives of the DBMS. 



HAREWARE 

Prime's DBMS operates on a Prime 400 syston or higher. The Prime 400 
and 500 are true virtual memory machines with a large address space 
(512 Megabytes per user for up to 63 users) . While they are designed 
specifically for time-sharing applications, any multi-user environment 
benefits from their memory management (for example, transaction 
processing) . 

In addition to the multi-user environment capability, the hardware 
contributes significantly to the speed, integrity, security, and 
upgrade flexibility of the entire syston. 

Speed 

Hardware design has aided overall speed in a Prime syston. Instruction 
execution speed is greatly enhanced by utilization of a cache memory 
which ronerabers data from recent menory references. Subsequent 
instructions referring to the same locations actually get their data 
from the cache. This in effect turns those monory reference 
instructions into register reference instructions, for a speed 
enhancement of approximately 3:1. 

Subroutine Calls; A direct hardware implementation for handling 
subroutine calls and passing arguments significantly reduces the 
overhead involved with calling subroutines. This is extremely 
advantageous to systems such as EBMS v*iere subroutine calling is heavy. 

Paging Speed; Paging speed has been enhanced by the new disk storage 
module because its record size is identical to the central processor 
monory page size; this simplifies buffering and paging. 

Page Size; The large page size, 2K bytes, increases the likelihood that 
desired information will be in high-speed memory since instructions and 
data that are used together frequently occur together^ e.g . , the 
contents of a record. Furthermore, the implementation of the storage 
structure of the E©MS has carefully taken advantage of this large page 
size. 
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Integrity and Security 

Integrity and security is an important aspect of database system 
requiranents. Prime's hardware environment includes internal 
transmission checking and a ring structure. 

Prime CPU memory has always been highly reliable because Prime hardware 

performs parity checks at both ends of every internal transmission. 

Itie manory for the Prime 400 and 500 machines is built in an 

error-correcting array: no word can be incorrectly tranatiitted except 
by multiple failure. 

Contributing to the integrity of the syston is enhanced security. The 
hardware is ring-structured (see Figure 2-1) to protect software and 
data. This ring structure enforces security by checking every memory 
address reference at the time it is generated by the hardware, and 
trapping unauthorized references to any lower-level ring. 




Figure 2-1. Hardware Ring Structure 
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PRIMOS resides in the innermost ring, where it is accessible only via 
legitimate calls. Ite DBMS resides in a rir^ of its own, just outside 
the PRIMCS ring. tteer programs reside outside the PRIMOS and iSMS 
rings and consequently cannot access anything in those rings (for 
example, password tables) except via legitimate function calls (viiich 
are examined for proper authority) . Any unauthorized attanpt to READ, 
EXECUTE, or WRITE in any ring from outside causes the offender to be 
trapped l^ the hardware and aborted. 

Ihe Prime storage module disk controller uses a sophisticated 
polyncanial algorithm capable of detecting error bursts exceeding 30 
bits, and correcting bursts up to 11 bits in length. This means that 
transient failures v*iich are largely fast intermittent errors, are 
virtually eliminated. In other words, unrecoverable disk errors rarely 
happen anymore, except on disks that are actually damaged. 

Hardware Upgrade and Expansion 

Prime has designed an upgrade and expansion capability into all Prime 
machines. 

The procedure for upgrading the CPU of a Prime machine to a Prime 400 
or higher consists solely of replacing the current boards with 
different ones. 

Similarly, the procedure for expanding high-speed manory consists 
solely of plugging in an additional manory board or replacirg an 
older/smaller/slower board with an improved one. PRIMOS adjusts 
completely anS autanatically to its new environment. 

Adding more disk monory requires only the additional step of altering 
the HIIMOS configuration table to reflect the addition. A comend 
exists to perform this function (see Section 9) . 

The architecture of the IBMS reflects this ease of expansion in its 
treatment of areas, allowing a database to expand naturally as new disk 
facilities become available. 



PFIMCG AFCHITECTURE 

The flexible architecture of the Prime hardware/software complex 
provides a substantial base for the DKIS. 

PRIMOS (Prime Operating Systan) itself has a great deal to offer the 
EBMS. Most obvious is its orientation toward multiple-users. Beyond 
that includes the provision of device independence. PRIMOS offers a 
syston in vAiich a user can simply log in and process files with 
virtiMtlly no concern for j^ysical protocol, regardless of his ajproach 
(interactive or not) or the services he desires (DBMS or not, etc.) . 
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File and Access Management 

PRIMOB also contributes the services of its File Management Systan 
(FMS) . PRIMOS interfaces to DKIS via a Random Access Manager (RAM) , 
provides utilities and an optimizing ANS FORTRAN IV Canpiler - the 
implementation language of Prime's EBMS. These software components 
make significant contributions to the speed and integrity of the EBMS, 
provide a foundation for its data structure, and add some lower-level 
capabilities. 

FMS is used as the undercarriage of the EBMS for its physical I/O 
managanoit. RAM provides the interface to DBMS, which accomplishes 
logical file managonent. 

RAM multiplexes the use of logical file units, thereby extending the 
concept of "virtual ization" to files. Ihis allows more files to be 
open than there are file units to use, thereby rendering these jAiysical 
restrictions invisible to the user. 

Crtie word "file" has no defined usage in the E8TG-71 Report, and 
consequently is reserved by Prime to mean the ^lysical entities upon 
vdiich the FMS operates.) 

Integrity in PRIMCg 

Another contribution by PRIfCS is its built-in integrity. EMS threads 
the E*iysical blocks of its files bi-directionally. A utility (FIXRAT) 
is provided to examine and repair file faults using this threading. 

RAM accomplishes concurrent update access via its total control over 
the buffer pool, v^ere it provides for multi- threading of user requests 
on the EBMS I/O and supports database recovery procedures. 

Security within PRIMOS 

Security is provided by PRIMOS through its access rights. FMS provides 
dual password protection at the physical file level: one password 
designated as "Owner" and another as "Non-Owner". These are each 
associated with different access rights. 

FMS provides different types of access rights: 

No-Access Delete-Only 

Read-only Delete-Truncate-Re^ 

write-Only Delete-Truncate-write 

Read-Wr i te Full-Access 

Buffer Pooling 

Another PRIMOS feature is the efficient memory management. FMS 
provides physical blocking and buffer-pooling, for efficient menory 
management at the data level (as opposed to monory management at the 
instruction level; i.e., virtualization) . 
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RAM provides logical buffer-pooling, the sharing of cannon files and 
distribution of data to requesting users. It selects its buffers using 
a Least-Recently-Used algorithm. 

This architecture provides cascaded levels of memory managonent, each 
adding advantages of its own, and building on the previous level. 
Virtual ization is extended in both directions from the page level 
(PRIMOS) to the file level at one end (by RAM) and the word level at 
the other (by CPU cache) , v**iile two levels of buffer pooling provide 
p*iysical (FMS) and logical (RAM) sharing. 

Data Structure Assistance 

PRIMOS construction and utilization of segment directories, essentially 
a file directory at a E*iysical level, provide a sound foundation (with 
FMS) for IBMS file structure. 

FMS provides direct access files v*ich EBMS utilizes to implement its 
data structure, simultaneously profiting frati the other fWS benefits 
mentioned above. 

Speed 

The newest and most crucial feature of PRIMOS to the DBMS is its 
ability to diare corancai progran space with multiple users. All EO^IS 
code is re-entrant, and is therefore shared single-copy code, but 
FRIMCe simultaneously treats it as though it were a user-bound 
subroutine. "Sius the advantages of shared code (minLtiizing paging) and 
user calls (no interrupts with low-overhead parameterization are both 
realized) . 

An»ng the single-copy items shared by the IBMS, besides PRIMOS arK3 rms 
itself, are the object schema (database model), the buffer pool, and 
tables of locks for controlling concurrent use. 

Maintainabil i ty 

PRIMOS facilities include its optimizing ANS FORTRAN Canpiler, allowing 
the entire DBMS to be written in a higher-level language. Itiis 
enhances its maintainability, yet the optimization minimizes the 
execution price of using a higher level language. 



IBMS ARCHITECTURE 

rms has been designed to place independent features into separate 
independent components, as enumerated below: 

1, Schema Data Definition Language (Schema EDL) Ccxnpiler 

2. COBOL Subschema Data Definition Language (Subschana DDL) Compiler 
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3. FORTRAN Subschema Data Definition Language (Subschema DDL) 
Compiler 

4. COBCti Data ManiE^ilation Language Pre-Processor 

5. FORTRAN Data Manipulation Language Pre-Processor 

6. Database Administrator Command Processor (DBACP) 



It is especially important to note that this separation of components 
permits definition of databases, generation of databases, and 
definition of private user views of these databases (subschona) to 
proceed independently, each in the language most suitable for it. The 
data manipulation conmands are pre-processed to produce MS COBOL or 
ANS FORTRAN final versions of the afplication program. 

The E8MS has also made use of modularity in that it has re-used 
techniques wherever legitimate (for example, set ordering and search 
keys share a single high-speed technique; database generation and 
database expansion are virtually identical) . Additionally, many 
low-level modules are used in more than one of the above components. 
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SECTIOJ 3 
STORAGE STRUCTURE SUPPORT 



INTRODUCTION 

This section describes some features of PRIME'S DBMS storage structure 
in terms of database layout, area layout, set format and search keys. 

The DBMS is capable of handling many different databases, each with a 
structure vAiich may be as complicated as a full network. 

Although each IBA controls the databases at his installation, the 
existence of passwords for all schema operations provides for a 
separation of authority. 



Database Layout 

The EEMS layout is illustrated in Figure 3-1. Multiple databases imply 
the need for a schema directory. Each entry in the schema directory 
holds an internal identifying number and a pointer to a table viiich 
holds information about the database. (schema table) . The schema 
table includes a subschana directory (vAiich lists the subschema 
associated with this schema) and definition tables which define this 
database with respect to space on jiiysical volumes, and all information 
contained in the schema DDL. 

The set and record definitions are the logical view of the database and 

the area definitions are the physical view. The implementation of 

their relationship is naturally a crucial determinant of the 
effectiveness of the entire s^i^ten. 



Area Format 

The Area definition is illustrated in Figure 3-2. Each area is divided 
into buckets. The buckets are chosen to be multiples of physical block 
size appropriate to house the specific record types assigned to then. 
Because of the relatively large page size (and its correspondence to 
block size) , this multiple is often 1, which contributes greatly to the 
effectiveness of paging in data records. 
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Figure 3-1 DBMS Layout, 
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Figure 3-2 Area Format. 
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Each bucket has its data records built down from the top with a 
directory at the bottcan. If necessary, any data record may span many 
buckets, but no matter how it expands or contracts, it will always be 
located through the bucket to v^ich it was originally assigned. 

Each record's database key is a pointer to it built of several 
portions: 1) the identity of the area within the area definition for 
the database (up to IK areas/databases) , 2) the bucket within the area 
(up to IM buckets/area) , and 3) the directory entry within the bucket 
(up to 255 entries/bucket) . Ihe key also contains the record type 
identifier (up to iK/database) . Since the record never changes bucket 
directories, the invar iance of the database key is preserved. 



Set Format & Search Keys 

The Set structure is illustrated in Figure 3-3. Sets are implemented 
via external multi-level pointer arrays which are a variation of 
"B- trees" (as described by Knuth) . The leaves of the B- trees are 
database keys. The nodes of the B-trees are indices of the next lower 
level in the B-tree. 

The Prime B-tree variation has several advantages. First, the nodes 
are doubly-threaded (left and right) for fast traverse. Second, the 
node size (fanout) is chosen on a type of set basis to reflect the 
average significance of database key occurrences for the type of set. 
Third, the association of nodes with page size leads to quicker access. 

A separate B-tree is also built for each search key of a set. Thus the 
E-tree mechanism does double-duty as a fast data inversion method. 

The entry for each owner occurrence in the set directory contains a 
pointer to the head of the B-tree relevant to that occurrence. 

To enhance traverse, the nodes of the B-tree are not only threaded 
bi-directionally, but point back to the parent node, aiding in 
insertion and ronoval of member entries. 

Any database may span any ntmber of available volumes, even though the 
IBMS I/O is founded on the EMS (vdiich cannot span volumes) . This is 
accomplished by restricting the files containing types of sets, calc 
tables and data base areas to a partition of a volume, while allowing 
different files to reside on any available volume. 
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Figure 3-3 Set Structure. 
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Given the orientation of the IBMS toward rapid access, one would expect 
speed to be a primary objective or the implementation approach. 
B-trees have demonstrable advantages for retrieval, update, and 
deletion v*ien compared to other data structures involving ordered sets. 

B-trees themselves are tunable (by varing fanout) for measuring space- 
time tradeoffs. Consequently, Prime has chosen to use B-trees 
exclusively, which adds uniformity to the efficiency of this ajproach. 



IDCATIOJ Mode 

Location mode G^LC, is implemented as a hashing algorithm into a table 
of database keys. Collisions are resolved by a threaded list overflow 
technique vdiich links all calc records having the same hash address 
together. Record occurrences with identical CALC keys (DUPLICATES) are 
also threaded. 

Placement of the data is of limited concern to a Prime DBMS Database 
Administrator (DBA) because of the Prime hardware optimizing 
randcan-sectoring technique; proximity other than same page is 
meaningless. To take advantage of the benefits of page-proximity, the 
IBA can designate record-types in sets to have a location mode v^ich is 
via set. The EBMS then stores these member record occurrences as close 
to their owner occurrence as possible. 

If no location mode is specified, a record is stored in the next bucket 
with available space. 

Ease of Expansion 

A major concern of the Database Administrator is the ccanplexity of 
expansion. PRIME'S DBMS is expandable through the following 
techniques : 

Areas can be expanded to include more buckets. Similarly, bucket sizes 
may be expanded. The IBMS automatically pads the extra space. A 
record re-organization may be requested at this time (PACK) to use the 
new space as efficiently as possible. 

Areas which contain no data can be initially defined for later 
expansion. This makes it possible to define a database v^ich is going 
to grow substantially over the years using today's sizes and today's 
storage space, and to simply expand old areas onto new devices, as the 
size of the data donands and the acquisition of more storage space 
permits. 

The use of buckets also highly localizes the effects of record 
alteration. Records can expand and contract with little effect upon 
other records (except for bucket-mates) . If new space is needed by an 
expanding record, a new bucket is acquired for it to flow into. A 
free-bucket chain is kept to minimize search time for new buckets. 
This v\diole process obviates the need for special overflow mechanisms. 
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and minimizes the price of "overflow accesses" paid by the physical 
systQT.. Garbage collection occurs only upon the request of the ESA so 
that update users pay no execution penalty for alteration of record 
size, unless the accumulation of alterations affect system performance. 

The fixing of the database key, the logical consistency and the saving 
of space more than cancel out the extra access needed to reach an 
extension of a record into another bucket. 



Space Utilization 

Field experience suggests that total space overhead ranges from 
approximately 5 to 60 percent, the latter occurring v*ien there is a 
great deal of structure. Yet, such files have generally been found to 
take no more space than their pre-DBMS counterparts, vAiich implies that 
the actual cost of this overhead approaches zero. The reason for this 
is simply that the redundancy required by non-DBMS systems requires as 
much space as Prime DBMS overhead. But there is a large improvonent in 
capability and flexibility (as in access speed) obtained by utilizing 
that same space for DMS-structured data. 
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SECTION 4 



THE PRIME VIEW CF SCME CCMMCN 
DBMS CCNCEPIS 



INTRCDOCTION 

This section discusses Prime's approach to implementing many coimion 
considerations. These include: 



O DATA STRUCTURES 

O ACCESS STRATEGIES 

O DATA INDEPENDENCE 

O PRIVACY 

o INTEGRITY 

o SHARING/aaCURREMT UPDATE PROTECTION 

O PRESERVING THE PHYSICAL INTEGRITY OF THE DATABASE 

O RECCVERY 

O DATA BASE ADMINISTRATOR SUPPORT 

Data Structures 

All data structures recoranended by EBTG-Tl are supported. These 
include ordered, tree, hierarchical, cyclic, and netvxjrk. However, as 
per IBTG, no two record types may own each other directly; a third 
record type must be invented to own them both, thereby associating them 
as desired. 

Access Strategies 

The supported access strategies have been partially discussed in 
earlier sections. There are access-via-set capabilities provided via 
the set directory with 1 inked- to-owner feature; there are 
indexed-entry capabilities in several forms: via a search key as 
provided by the B-trees or via a search key provided in the same 
manner, or via the CALC function, hashing values to scatter table 
containing database keys. There is also direct access via the database 
key. 
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Data Indeoendence 



The data independence provided by the DBTG is realized by the 
definition of subschemas and their relationship to the schema. The 
E8TG states that a Subschema Data Definition Language (DDL) and a Data 
Manipulation Language (IML) should exist for each application program 
language vihich will interface to the database, but DBTG-71 considers 
only COBCL. 

Prime has implemented the subschema Data Definition Languages (DDL) and 
Data Manipulation Languages for both COBOL and FORTRAN. While the 
manipulation languages are nearly identical and very English-like, as 
the E8TG recommends, the Subschema Data Definition Languages reflect 
their host languages quite clearly. 

COBCL and FORTRAN recognize different data types and have different 
naming conventions. Their respective ODL's address themselves to the 
appropriate data types for each language. Since implicit data typing 
is permitted by FORTRAN, it is also permitted by the FORTRAN DDL: the 
implicit data type is that of the schema (or an appropriate default 
variation if that type does not exist in FORTRAN) . 

During conpilation, the User Work Area is constructed as a COMMCN Block 
for FORTRAN and as WORKING STORAGE declarations in COBOL. A tabular 
listing of the User Work Area is provided by the subschema conpilers, 
thus giving the user a conplete definition of his work area, including 
all the itans and their types. 

All schemas and subschemas are ccxnpiled into an object table for faster 
reference. Hence, whenever a schema changes, it and all its subschemas 
must be recompiled. Of course, if a subschema is changed, it must be 
recompiled . 

Changes to subschemas affect all amplication programs using than, which 
must generally be recanpiled. All changes to schema currently require 
such recOTipilation, since all subschema are affected. 

Were this not true, the enterprise would be faced with a particularly 
dangerous form of data independence. Changes which affect the User 
Work Area imply that run-units using that work area are now outmoded. 
They must at least be checked; particularly if the definition of the 
database has been changed, or the view of it represented by a 
run-unit's subsct^ma has been changed in previously existing run-units. 
However, if an older version of a subschema is deleted, run-units 
referring to it will be trapped by the IBMS. This represents an 
enhancement to the potential integrity of the database. 

The Prime EBMS provides an entirely new level of data independence 
called "dynamic reference", based on really not caring about the actual 
data contents. This is the type of data independence vrfiich general 
text editors, dump routines, and other utilities appear to have. DBMS 
achieves this by delaying binding until run- time. The schema and 
subschema to be used by the run-unit need not be declared until 
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run- time. Thus generic utilities vdiiich view the schema through any 
subschema can be written. This capability is described further in 
Section 5, Extensions. 

Privacy 

The natural attributes of the hardware and software allow an effective 
Privacy capability. Privacy is maintained well beyond the capability 
set down by the EBTG specification. The PRIMOS Password and Protect 
capabilities are used here. The Hardware Ring Structure provides a 
measure of security unachievable in any other fashion. Lists of EBAs 
and their privacy keys may be kept in raonory and be absolutely 
inaccessible to unauthorized personnel. 

For further protection, keys are supplied at run time. This means that 
access to a source listing is not access to the keys it must use - for 
the key can be supplied interactively at run-time. 

As recommended by IBTG, every operation on every DBMS entity can carry 
a separate lock. These locks may be literal or variable. Those which 
are declared as variable can be changed by the DBA at his discretion. 

Integrity 

The Prime EBMS provides integrity in many ways already mentioned. The 
hardware provides parity checks at both ends of all gating paths, the 
CPU memory and disk controller both utilize error correction 
algorithms. The MS provides bi-directional threading of all files and 
a utility to provide file maintenance. RAM provides control over 
logical sharing of the data. 

The EBMS also prepares extensively for recovery of data in event of 
failure, including before-imaging, after-image journalling, and 
database transaction-oriented delayed incremental updates. 

Sharing/Concurrent Access with Most DBMSs 

In most database systems, concurrent access to data present no problems 
as long as data does not change. If any users change shared data, 
several problems arise. 

Insuring logical consistency, when shared has changed: If any user is 
changing shared data while one user is attempting to analyze the data, 
the analysis may be meaningless. Logical inconsistencies may flaw the 
analysis since the analysis does not represent a single state of the 
data. 

For example, suppose that user A is reading a personnel database to 
produce a list of employees by department. If another user transfers 
employee X from a department that has been listed already to a 
department that has not yet been listed, the employee X will appear to 
be a full-time employee to both departments. Thus, user A has an 
inconsistent view of the data. 
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Lost updates vAien shared data has changed: Suppose that the following 
sequence of events occurs: 

user A reads item X 

user B reads itan X 

user A replaces X by X + 10 

user E replaces X by X + 20 

Notice that the update by user A has been lost. This occurs because 
user B read the same value of X as user A rather than reading the 
result of the update by user A. 

Locks are often employed to eliminate the above problans. Parts of 
files are locked vdiile they are being analyzed or updated. Not only 
does this raise the problon of lock managanent, but it can lead to a 
situation known as deadlock. Consider the following sequence of 
events: 

user A locks record X 
user B locks record Y 
user A requests record Y 
user E requests record X 

User A waits on user B, while user B waits on user A. Neither user can 
proceed. One user must be aborted. How can a decision be made as to 
vAiich user to abort? V^at should be done about any records that have 
been modified by the user that is selected for abortion? 

Sharing/Concurrent Access with Prime's DBNE 

The Prime EBMS eliminates the problems of inconsistent analysis, lost 
updates, deadlock, and many other problans resulting from concurrent 
update of files by introduction of Database Transactions (DBTs) . DETs 
are used to groip data accesses which must be performed together to 
insure consistency of a database. A DBT is introduced by a START 
TRANSACTION DML cotimand and is terminated by an END TFANSACTIC»sf command 
or an ABORT TRANSACTION. 

Itiere are two types of lETs: Retrieval DBTs and Update DBTs. The two 
types of DBT provide different sets of features. 

The Retrieval IBT provides the user with a consistent view of a 
database even though concurrent users may be updating the database. 
This is done by saving before- image copies of modified blocks. When a 
Retrieval DBT requests information from a modified block, it is given 
the before-image copy of the block as it existed v\^en the Retrieval DBT 
started. Thus, all updates initiated since the beginning of the 
retrieval transaction are transparent to the Retrieval DBT. 

The Update EOT provides a consistent view, prevents lost updates, 
prevents deadlock, and provides rollback of updates. As an L^ate DBT 
modifies blocks, before- image copies of the blocks are saved. The 
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before-images are used to rollback a transaction vtien a user aborts the 
transaction or v*ien a transaction is aborted automatically. 

An Update EBT is not permitted to read or write a block that has been 
modified by a concurrent l^ate DBT. If this restriction is violated, 
the offending transaction is notified that it must abort. The 
transaction can perform its own recovery before aborting the 
transaction. The transaction will be aborted automatically if it 
attempts to execute any DML conmand other than ABORT TRAMSACTION. 

Since concurrent Update DBTs are permitted to proceed only if they 
operate on different subsets of the database, a consistent view of the 
data is insured, and lost updates are eliminated. Transaction rollback 
provides recovery from deadlock and recovery from many errors including 
DML program errors, certain DBMS errors, and even halts due to hardware 
or software errors. 

When an Update IBT aborts because of concurrency conflict, the program 
can immediately begin another DBT to attempt the same update. 
Concurrent update conflicts are transient and usually clear very 
quickly. 

The key elements in the implementation of DBTs are update transaction 
numbers, lists of completed transactions, and before-images. Mien an 
Update IBT starts, it is given a new transaction number and a list of 
transactions that have canpleted. An Update IBT is only permitted to 
read and write blocks that were last written by transactions that are 
in the list of completed transactions for the Update DBT. Whenever an 
Update IBT modifies a block, its transaction number is written into the 
header of the block. Before the modification is done, a before- image 
copy of the block is saved in a before- image file. The before- image 
and the modified block are linked together for use in transaction 
rollback, other recovery procedures, and Retrieval DBTs. 

When a Retrieval DBT starts, it too, is given a list of ccanpleted 
transactions. If the Retrieval DBT attempts to read a block that was 
written by an incomplete transaction, the chain of before-images for 
the block is searched backward for the most recent block that may be 
read by the Retrieval DBT. 

By using Update DBTs, the blocks dynamically involved in an update are 
inaccessible for other updates. An exception occurs only vrfien one 
Updated IBT actually attonpts to access data vdiich has been modified by 
another concurrent Update EOT. In addition. Retrieval DBTs never lock 
out Update IBTs, yet consistent data is always available to Retrieval 
IBTs in the before-images. The use of DBTs results in a much smaller 
fraction of the database being locked than schemes which require 
pre-locking of data to be updated to be retrieved. In particular, 
portions of the database may be dumped while others are concurrently 
running against those same portions, since a dump program can be 
progrcBwned as a single retrieval IBT! 
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Preserving the Physical Integrity of the Database 

In the overv^elming majority of cases, each DBT will be interested in a 
very few records for a very short time. No conflicts of any sort will 
occur, arK3 this entire syston will be utterly transparent, because the 
new version of each record replaces the old in the very same spot and 
no additional accesses of any sort are required. 

The only inconsistencies that can creep into the data base under this 
system are errors introduced by amplication programs which are 
authorized to make changes and do so incorrectly (i.e., faulty user 
program logic) . 

Operations which must affect significant portions of the database are 
performed without concurrency at the request of the IBA, which is 
effected by locking the entire schema gainst any access. The 
operations are: 

Conmand Function 

MMXATE Allocate space for the files of the 

database and preformat it. 

EXPAND Allocate more space for the files of 
the database. 

PACK Garbage collect and reorganize the 
specified areas/calc files. 

SAVE/RESTORE Copy the database to/frcan 
magnetic tape. 

NOTE: 

These facilities are with the DBACP and are described in 
Section 9. 



RECOVERY 

Many kinds of errors, exceptional conditions, and failures can occur in 
the use of a DBMS. A sophisticated DHffi must provide a variety of 
recovery techniques to assure the reliability of the system and the 
integrity of the data. 

The Operation of the Run-Unit 

The DML Command Process (DMICP) performs extensive validation of each 
EML command issued by a run-unit. The EWL languages provide facilities 
for a EML program to trap all nonfatal errors in two ways. Each DML 
command may include a list of errors that the program wants to trap and 
v\iiere to go if an error is detected. A run-unit can also check the 
error status in-line after each DML command and perform the appropriate 
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recovery if necessary. When the DMLCP detects an error during the 
execution of an UPDATE DML caimand, it rolls back the database to its 
status before the erroneous DML ccranand. The run-unit is given the 
opportunity to recover from the error. If another DML command is 
attanpted before the error is cleared, the DMLCP aborts the run-unit 
and automatically rolls back the entire transaction (if one is active) . 

Roll Back 

Several kinds of exceptional conditions can occur during concurrent 
update of files. Ihe most frequent exception is vAien concurrent 
transactions attempt to update the same block. Concurrent update 
exceptions can be trapped by the user in the same manner as other DML 
errors. After a concurrent update exception has occurred, the DMLCP 
will always roll back the transaction v^en the next ABORT TRANSACTION 
cOTTiand is executed. If the DML program detects an error in any way 
during a transaction, it can execute an ABCKT TRANSACTIOJ conmand, and 
the TMUZP will roll back the transaction. 

The Recovery Processor 

If a oyiL program does not terminate properly, it can leave the database 
in an indeterminant state. Termination can be caused by the program 
user hitting the break key, by the DML program exiting before ending a 
transaction, closing the areas, and exiting the ISMS, by fatal errors 
in the 1»!L program, the EMLCP, or system software (errors such as 
division by zero, invalid addressing, end of file, etc.) , or by a 
systan halt due to hardware or software failure. The Prime EEMS 
includes a recovery processor. The recovery processor includes 
commands to report the status of transactions and DBMS usage and to 
roll back all incomplete transactions and to clean up DBMS control 
tables. 

Sonetimes a DML program that appears perfectly correct to the DMLCP 
introduces errors into a database. Perhaps the DML progran deleted or 
modified the wrong record; it may have deleted the entire database. 
It is also possible that a new version of the DMLCP could contain some 
bugs that introduce errors into a database. 

Recovery Facilities 

The Prime DBMS provides a couple of facilities for recovering from the 
errors mentioned above and other catastrojiiic errors. Before a block 
in the database is modified, a before- image copy is saved in a 
before-image file. A modified block is written out to disk, a 
duplicate copy is written to the after-image file. All blocks are 
labeled by the transaction that last modified the block. In addition, 
a message is written into a log file Whenever a transaction starts, 
ends, or aborts, and vtenever a block is modified. Before- imaging, 
after- imaging, and logging can be turned on and off separately by using 
the Database Administrator's Command Processor (DBACP) , see Section 9. 

Ihe I/O subsysten of the IBMS has been designed to insure that the 
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recovery files are robust to system halts and other failures. 

The recovery processor can examine the log file to help identify faulty 
transactions and to analyze update activity since the faulty 
transactions. The recovery processor can roll back the database using 
the before- image file or roll the database forward using a saved copy 
of the database and the after image file. A copy of a database can be 
saved and restored by use of PRIMOS MAGSAV/MAGRST or through use of 
SAVE/RESTORE in the Database Administrator's Module. The selection of 
rollback or rollforward depends on the size of the database, on the 
volume of updates since the last database save, on the volume of 
updates since the errors, and on the type of failure. 

Analysis of the log file may scxnetimes indicate that a restore and 
rollforward of part of the database will still guarantee integrity of 
the data and speed up the recovery process. The recovery processor 
includes features to expedite this. 

Recovery from a disk head crash can be done by restoring the affected 
areas from a database save and rolling forward using after-images. 



DATABASE ADMINISTRATOR SUPPORT 

Pr i vacy-Locking 

Each installation's databases are overseen by Database Mministrators 
(DBA) . Each IBA potentially has control over all databases at 
installation. However, a database may be removed from a DBA's 
authority by Privacy-Locking its usage, thus barring those DBA's vdio 
are not authorized to know its keys. 

Each installation may define to the DBMS how many of the DBA's 
(including none) will be privileged IBA's. These IBA's are understood 
by the mMS to know all necessary keys, and thus have special 
privileges useful in database debugging and assisting other IBA's and 
applications programmers. 

Caretaker Functions 

The function of the DBA is essentially that of caretaker of the 
database. The DBA creates the model, populates it, monitors it, 
tinkers with it, revises it, improves it. Help is provided to the DBA 
in accomplishing this multifarious task by the Database Administrator 
QjjTimand Processor (DBACP) . 

Because the IBA functions are so far-ranging, each can be guarded by 
its own lock. In fact, since all the locks are single-purpose, an 
extensive dialog is often required for a IBA to acccxtiplish his 
objectives. These safeguards are intended to protect against careless 
errors. 
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Creating the Database 

The EBA ccmponent helps the TBA in a number of vays. The earliest 
function v^ich must be provided is database creation. 

Definition of the schema, it should be recalled here, is outside the 
realm of this component, since a separate canponent, the schema DDL 
Compiler, exists solely to perform this task. 

Anyone may use the WL to define, and even compile a schena; but only 
a TBA may allocate space to the schana and populate it with data. 
There is an advantage in this. A DBA can assemble a staff of technical 
experts, but can investigate the proper modeling of it, experiment with 
possible models, and ultimately determine the best one, technically, 
for the EBA to use. 
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INTRCDXTION 

Most of the capabilities already discussed include functional and/or 
operational extensions to the EBTG-71 Report reconmendations. This 
section focuses on the more important global extensions that have been 
mentioned, and some specific ones that have not. 



GLOBAL EXTENSIONS 

Database Transactions (DBT's) 

The existence of DBT's and their value has been fairly extensively 
discussed. The existence of the START and EXIT/ABORT transaction block 
structure allows dynamic implicit locking of data instead of static 
pre-locking in concurrency situations. 

INVOKE Coimiand 

The INVOKE conmand is executable. Prior to executing the INVOKE 
command, a run-unit is not associated with the DBMS. The EXIT/ABORT 
IBMS conmands disconnect DBMS from the run-unit. DML commands 
occurring outside the scope of an INVOKE are ignored. Multiple 
INVOKE-EXIT/ABORT pairs are permitted, but all must reference the same 
subschema. 

Keys 

Keys are supplied interactively at run time for more privacy. It is 
also easy for a DBA to change keys for variable privacy locks. 

CN ERROR Clause 

An CN ERROR clause applicable to each DML conmand allows the 
application program to specify alternatives for each different type of 
possible error on that command, so the program can handle them in 
vAiatever fashion it chooses (barring required ABORT) . Ihe CN ERROR 
clause may specify either GO TO label or CALL external value. 

Dynamic Reference 

Dynamic reference provides total data independence for special 
purposes, by delaying binding to a schaiia/subsGhGina until run time. 
The names of such database entities as sets, areas, record- types, and 
items may therefore be referenced dynamically, as conversational input 
via an interactive terminal, for example. An application program 
written to utilize this facility can reference the subschema entry 
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which defines the supplied name and can extract any of its 
characteristics (e.g., for itans: type, PICTUPE, PICTURE length, data 
length, and null-representation) as well as operate on the data values 
thonselves. 

This is the type of data independence that facilitates the 
implemoitation of general utilities, such as general text editors, dump 
routines, and on-line interactive query languages. 



SPECIFIC EXTENSIONS 
Item Type Extensions 

There are many extensions at the itan level. Extended data types 
include double-precision nunbers, both integer and real, plus the types 
TIME, EftTE, and Ca3E. TIME and DATE are self-explanatory, and in both 
cases a special internal format provides for compilation of these 
values on disk. CODE associates a literal string for external (human) 
consumption with space-saving internal code types. These codes are 
indices into a cannon stored decoding table. Coding in both directions 
is automatic. 

The code table is treated as a single literal pool in each database. 

Literal strings v*iich are represented by codes (v*iether the same or 

different) for more than one iten are not repeated in separate per-item 
tables. 

The Prime I»MS also permits variable-length character strings. It 
autonatically stores such strings without any trailing blanks. The 
length attributed to these strings for accessing purposes is taken from 
the invoked subschona User Mbrk Area at run-time. The reserved space 
need not be large enough to hold every value of the item in the 
database; only those v*iich are accessed. The EBMS will fill with 
trailing blanks as necessary to reach the size required by the 
subschema. 

No single value is used to represent a null value universally. The 
representation of the null value depends on the data type and is chosen 
for efficiency by Prime. 

Data Aggregates 

There is a very significant extension to data aggregates, and that is 
that any data aggregate may occur a variable number of times, 
regardless of whether it is part of, or contains, any other data 
aggregate. This feature cannot yet be utilized in a COBOL subschema, 
because it is beyond the ability of ANS (XBOL. 

One significant use of this feature works well with CODE item types to 
provide exception reporting without wasting space. The usual procedure 
for this is to encode the standard values (responses) with an 
additional code for exceptions (often, "Other, Specify"). 
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rr,v._ „_^ ^ •;<:■,•-,-, 4- ■i«r^ r,f 4-Ktc PvropHon would be a -strinq which rarely 
appeared. Defining it as a variable length and/or variable m 
occurrence would result in a minimum of waste in this situation. 

FOETRfiN Record Overlays 

An extension concerning records is the ability to specify that 
different record types shall share the same space in a FORTRAN User 
work Area (COMMON Blocks) , in consonance with the FORTRAN concept of 
BQUIVAI£NCE. 

ailSS IONS/RESTRICTIONS 

No description of the DBMS would be complete without identifying 
current oimiissions vis-a-vis the EBTG-Vl Report. These are: 

1. Set Mode is always system standard: B-trees, 1 inked- to-ovner. 

2. Ttemporary areas are not implemented. 

3. The CHECK clause - CHECK IS PICTURE is not implemented. 
CHECK IS RANGE is limited to numeric values 

CHECK IS LIST is confined to character strings 

4. Itie ORDER D^L Comiand is not implemented. 

5. New Groups in the Subschana 

NO data aggregates or naming groups are permitted in the 
subschema unless they also occur in the schema upon which 
that subschema is based. 

6. E^amic Sets are not implemented. 

7. ENCODING/DECODING is not implemented. 

PENDING 

Sane current omissions are already planned but not available in the 
first release 

1. Procedures 

The procedure facility is canplex and far-reaching. The 
state of this facility has delayed the availability of 
CK CLAUSES. Procedures will also be 
available in PRIVACY, CALC and CHECK clauses. 

2. DBMS Access to MIDAS Files 
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Afplication programs can access both DBMS files and 
Multiple Index Data Access System (MIDAS) files. 
Presently each type of file roust be accessed by using 
its own access system. Extensions to both MIDAS 
and DBMS will make it possible for MIDAS files to 
be accessed by DBMS caimands. 

3. Testing 

Testing new DML programs is very time-consuming if a 
test database must be created. It is often difficult 
to obtain a meaningful test in a synthetic 
environment. Testing update DML programs on an 
active database can obviously have disastrous effects. 
The Prime DBMS facilites testing of update OIL programs 
by providing test mode. 

When a DML program invokes a schema for test mode, all 
transactions are considered retrieval transactions. 
Differential file techniques are used to store the 
updates in a scratch area that is private to the test 
mode program. The database is never modified in any 
way by a DML program in test modes. Other run-units, 
whether in test mode or not, are completely unaffected 
by a run-unit in test mode. 
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SECTION 6 
DBMS FILES 



INTROXJCTIOT 

Itiis section defines the database types of files that serve the 
Database Managanent System. 

The database files are subordinate to segment directories, one segment 
directory per volume per schema. A database file may, thus, be 
uniquely identified by schema name, volume name, and segment directory 
entry nutiber (INTEGER*4) . This information is displayed by the VERIFY 
commands of the EBACP. 

There are eight types of files associated with each schema or database: 

o Schema table (one per database:) 

o Subschema tables (one per subschema) 

o Area files (one per area) 

o Set files (one per set) 

o Calc files (one per record with location mode calc) 

o Log file (one per sctema) 

o Eefore-Image file (one per schema) 

o A^ter-Image file (oie per schema) 

SCHEMA TABI£ 

The schema table is a tabular representation of all of the information 
supplied in the schema source DDL. P^lso included in the schema table 
are: volume/entry identifier for each database file other than the 
schana table, keys for variable locks, and a directory of all 
subschemas for the schema. 

SUBSCHEMA TABLE 

The subschema table is a tabular representation of all of the 
information suj^lied in the subschema source WL plus privacy 
information from the corresponding schema constructs. 
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APEA FILE 



Area files are divided into equal lengt±i sections called buckets. 
Record occurrences are stored in the bucket frcan the top down, A 
directory of all record occurrences stored in a bucket grows upward 
from the bottom of the bucket. When there is no more roan in the 
bucket for another directory entry and at least part of a record 
occurrence, the bucket is flagged as FULL, and the next bucket with 
available space is used. 



SET FILE 

Set files contain a Set Directory and B- trees (see Knuth Vol. 3, 
Section 6.2.4) representing set occurrences. The set directory entries 
are of fixed length for each set with all free entries linked together 
on an available entry list. There is one B-tree node space for each 
member list (one list per member if "ORDER IS SORTED;" else one per 
set) as well as one node space for each search key for all monbers of 
the set. The B-tree nodes are of fixed length for each node space with 
all free nodes linked together on an available node list for each node 
space. 



CALC FILE 

Calc files contain a hash table v*iich is used to find the IBK of a 
record using a table entry nimber derived frcsn hashing the concatenated 
values of all items declared as CALC keys for this record. At any time 
a table entry may be used or it may be flagged as empty (never used) or 
freed (used but record deleted or calc key(s) modified) . 



LOG FILE 

The log file is a sequential file for writing messages regarding 
transactions and updates. The log file is intended to assist in 
recovery from serious database damage such as disk head crashes. The 
log file may grow very rapidly v^en there is a lot of transaction 
activity and update activity. The log file should be cleared 
periodically using the CLEAR LOG canmand of the DBACP vihen the database 
is inactive and secure. Message types are ASCII strings, start 
transaction, end transaction, abort transaction, and update a block. 
The pointer to the next available location in the log file is located 
in the transaction tables of the before- image file. 



BEFORE-IMAGE FILE 

The before-image file consists of the transaction tables and the 
before- images. The transaction tables contain transaction numbers, a 
list of completed transactions, information for the before-image queue, 
the log file, and the after-image file and other information necessary 
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for support of concurrent update of files. The rest of the 
before- image file contains before- images. Just before an i^ate is 
made to a block in a database file, a copy of the block is saved in the 
before- image file. The blocks are arranged as a queue v*iich is 
cyclically reused. Pointers describing the before- image queue are kept 
in the transaction tables. 



AFTER-IMAGE FILE 

The after-image file is a sequential file of after-images. An 
after-im^e is a copy of a modified block. After-images provide the 
redundancy required for a recovery after tragedies such as disk head 
crashes. An after-image is written v^en a block is depaged because of 
overflow of the buffer pool or at the end of a transaction. 
After-images are written at the end of the after-image file. A pointer 
to the next available location in the after-image file is located in 
the transaction tables of the before- image file. 
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SECTION 7 
DATABASE GESSIERATIOJ & ACCESS 



INTRODUCTICa^ 

This section discusses what is involved in creating a database. It 
includes some important considerations of file allocation and the steps 
required to create a database. 

SCHEMA CREATION 

The Schema DDL Compiler generates the schema table and enters the new 
schona name and number ard volume name for the schema table in the 
syston directory of all schemas. 

See the schema EDL manual for a complete description of the Data 
Definition Language and how to use the schema compiler. 



FILE ALLOCATION 

The files for a given database are created and initialized using the 
ALLOCATE FILES command of the IBACP (Section 9) . 

To assist the DBA in constructing the database, the ESACP queries him 
about quantities for vAiich no fixed value was defined in the schema, 
such as: 

o The average length of variable-length strings. 

o The average number of occurrences of a variable-occurrence data 
aggregate. 

o The maximum number of occurrences of each record type. 

o The average number of manual inserts of each manual member of 
each set. 

From the estimates given by the IBA, the IBMS calculates the exact 
storage requirements of each file constituting the database, and 
informs the EBA of space usage statistics including: 

o The length and node-size of each E-tree. 

o The nunber and size of each collection of buckets. 

o The size of CALC file tables. 

o The data-utilization ratio (the inverse of the overhead ratio) . 
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The DBA need not proceed immediately using these figures; he can test 
various assumptions and adjust his estimates to arrive at a final 
configuration v^ich he feels best suits the enterprise's current needs. 
In this way he may manage to reduce overhead, caipare various versions 
for efficiency, or find a way to force the database into a smaller 
space occasioned by the size of his current syston. Because of the 
ease of expansion, the DBA is free to select a version of the database 
vdiich adjusts today's data needs to today's system, even though he 
knows this version to be much smaller than ultimately intended. 

Having selected the satisfactory space configuration, the DBA can then 
actually allocate the files. The EBMS requests a volume identification 
for each AREA, SET, CALC TABLE, BEFORE-IMAGE FILE, the LOG, and the 
AFTER-IMAGE FILE associated with the schema. Thus, though DBMS depends 
on FMS, which cannot span volumes, a database can span volumes because 
each file is confined to a single volume itself, though the collection 
of files may cover all available volumes. The ffiA assigns all files to 
available volumes, even those he originally defined only for future 
usage. AREAS defined in the schema v*iich are not used initially can be 
defined to have one occurrence of a record in than during the 
space-calculation dialog, and thus require minimal space until they 
actually are put into use. 

Oily a mA can allocate database files. A DBA can also clear the files 
of all data, or delete the files and data. These conmands (ALLOCATE, 
CI£AR, and MILETE) must operate on all files of the database to ensure 
its integrity (refer to Section 9 for a description of these commands) . 
The creation dialog is recorded, as are all EBACP dialogs, along with 
the date, time and name of the ISA. This record may be filed for later 
scrutiny to recall the origins of the database and the founding 
estimates. 

After allocation of the database, it must be populated with data. The 
TBA defines a subschema for database loading and writes an application 
program in the language of his choice (CX)BOL or FORTRAN) , which 
utilizes the DML to construct the database via updating EWL ccanmands. 
This gives the IBA complete control over the populating process. 

The actual steps for creating a database are: 



1. Define the schema and compile it into a schema table (Schema r»L 
Compiler) . 

2. ALLOCATE Store space for the database (ALLOCATE files in DBACP) . 

3. Define a subschema to be used by the loading program and compile 
it into a subschema table (FORTRAN or COBOL Subschema DDL 
Compiler) . 

4. Write the database load program for this database. 
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5. Pre-process the load program into standard host-language form 
(fOFTRAN or CtBCL DML pre-processor) . 



6. Gcmpile and run the loading program. 
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SECTION 8 
DATABASE MAINTENANCE TECHNIQUES 



INTRODUCTION 

After the database is created and put into use, the DBA must monitor 
its use for loss of efficiency and provide for its expansion and 
re-organization vAien or if necessary. The need for reorganizing must 
be determined from space utilization figures. The PRIMOS system 
accounting data, which includes a measure of paging activity, can be 
used as an aid in this context. 

A DBA can request space utilization status reports at any time. These 
reports detail the space utilization figures for all areas, sets, CALC 
tables and all recovery files for each requested database. 

Whenever the IBA observes excessive paging activity, or the impending 
overflow of allocated space, or lengthening response times due to 
excessive accumulation of record alterations, he can initiate garbage 
collection. 



MEDIA SPACE VERIFICATim 

At any time in the life of a database, the status of the various files 
in terms of space usage may be ascertained using the various VERIFY 
ccsnmands of the DBACP. If file space usage is verified frequently, 
there is less chance of the TML conmand processor error "MEDIA SPACE 
NOT AVAILABLE" being encountered (see Media Space Clean-up and 
Expansion) . 



MEDIA SPACE CLEAN-UP AND EXPANSION 

To make more media space available, space no longer in use (due to 
DELETE record DML comiands) may be freed for DBMS use using the PACK 
AREA ccarmand on any area frcan which records have been deleted since the 
ALLOCATE FILES or the last PACK AREA ccxtimand. If insufficient space is 
freed using the PACK AREA caimand, or media space is not available in 
one or more set or calc files, the IBACP command, EXPAND FILES, must be 
used. After an EXPAND has been executed, it is advisable to PACK any 
areas in which the bucket size was expanded to optimize space usage by 
trying to concatenate any record occurrences which were continued in 
other buckets. 



The expansion dialog is similar to file allocations, expanding only 
those spaces vrf:iich actually require expansion. Since the revised 
definition is at least partially based on actual usage, it could turn 
out to be more efficient. The EBA may wish to investigate expansion 
simply to see if a more efficient configuration results frcan using 



July 1977 



SECTION 8 IDR3043 



actual figures. 



If many records with location mode calc are deleted or the calc keys 
modified, the calc file may becone filled with freed (no longer used) 
hash table entries, thus increasing the number of hash table probes for 
success or failure. Ihis condition may be remedied by using the PACK 
CALC catmand of the IBACP v*iich rehashes the entire table. 



CCNCURRENCY 

A run-unit vrfiich updates a database must have exclusive use of the 
database files unless concurrent update is allowed (see ALLOW 
CCNCUFPENT UPDATE in E8ACP) . Since the concurrent update mechanism 
makes use of be fore- images, a before- image file of "sufficient" size 
must have been allocated and before- imaging must be turned on (see 
START BEFCRE-IMAGING in EBACP) before concurrent update can be allowed. 

The size of the before-image file is requested from the user by E8ACP 
during the ALLOCATE FILES dialog as a percentage of the total database 
file size. This can be estimated by multiplying the percentage of the 
database accessed by an average update transaction times the maximum 
number of concurrent update run-units using this schema. The 
percentage of the database accessed is roughly the ratio of the number 
of record occurrences accessed by an average update transaction to the 
total number of record occurrences to be stored (i.e., the sum of the 
answers given for the individual record types in the ALLOCATE FILES 
dialog) . 

NOTE: 

Before- imaging may be either on or off when concurrent update 
is disallowed. 



RECOVERY 

There are two types of D^S recovery available: roll back a database 
to a given point, or roll forward a database from a check point (see 
SAVE SCHEMA in EBACP) to a given point. Roll back is implemented using 
before- imaging and roll forward using after- imaging. The points to 
which a database is rolled back or forward is determined using the 
logging function of the IBMS (see the BEFORE-IMAGING, AFTER- IMAGING, 
and LOGGING canmands in DBACP) . 

Although before-image, after-image, and log files are allocated and 
before- imaging, after-imaging, and logging may be turned on arxS off, 
the actual roll back and roll forward processors have not yet been 
implemented. These will be documented and distributed to IBMS users 
with Rev. 14 of PRIMOB. Lhtil then, users are advised to backup 
active databases with the SAVE SCHEMA conmand in DBACP as described 
below. 
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NOTE: 
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ip3ate. 



DATABASE BACKUP 

It is advisable to keep one or more copies of an active (frequently 
altered) database on magnetic tape for backup using the SAVE SCHEMA 
cojimand of the IBACP. It is also advisable to save a database before 
using any volatile EBACP ccxnmands such as PACK AREA or running a DML 
program viiich "cleans up" the database by deleting record occurrences 
(periodic purging) . 



DML CCM1AND PROCESSOR CLEAN-UP 

If a DML program does not terminate properly, it can leave the data 
base in an indeterminate state. Termination can be caused by the 
program user hitting the break key, by the DML program exiting before 
ending a transaction, by fatal errors such as division by zero or by a 
systan halt. After a DML program halts abnormally, the DML clean- up 
program, CliJP, should be run fran the same terminal. CLUP rolls back 
the current transaction if one is active, closes files, releases locks, 
and cleans up EBMS control tables. If a DML user is uncertain about 
the termination of the DML Program, the user should run CLUP. If the 
user is not found in the EEMS, CLOP has no effect. Executing CLUP can 
never have an adverse effect. 



PRIVACY KEYS 

Privacy keys for variable locks may be displayed or altered at any time 
(see various KEY and KEYS ccxnnands in DBACP) . This does not affect any 
run-unit which has already gained access to the data vdiose keys are 
concurrently changed. 
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SECTIC»J 9 
DEA COMMAND PROCESSOR (DBACP) 



INTRODUCTION 

The DBACP (Database Administrator Cojnmand Processor) is an interactive 
processor vdiich allovs the Data Administrator to create, investigate, 
and change the various files within databases. Several cormands are 
available to all users for verification of the current status of 
database files. All other conmands are restricted to use by those 
people officially designated as Data AcSininistrators. 



PROCEDURES 

To initiate DBACP, the user must log in and type: 

DBACP 
DBACP pranpts for each new contnand by displaying: 

READ^ 
SCHEMA schema-name READY 
The user may exit IBACP by typing the ccsnmand: 

QUIT or Q 

After each canmand the elapsed, CPU, and disk I/O timings are displayed 
in seconds. 

Concurrent Run-Units 

Those IBACP ccxnmands vdnich alter an existing database or set system 
flags which limit run-unit access to the schema may only be executed 
when no run-units are currently running against the schana specified. 
Those commands which affect database files, such as the EXPAND and PACK 
commands, automatically lock the schona as well as checking for 
concurrent usage to prevent further invocation of the .schema while the 
ccmtiand is being executed (the UNLOCK SCHEMA command must be used to 
free the schema) . If no run-units are currently accessing the schona, 
the command proceeds. If there are run-units currently accessing the 
schema the run-unit user numbers are displayed and the user is asked: 

DO YOU WISH TO ABCa?r THE RW-UNITS? 

If yes is typed, the run-units are aborted and the command proceeds, 
else the user is asked: 
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DO YOU WISH TO WAIT FOR THE RUN-UNITS TO FINISH? 

If no is typed, the cormand is aborted; otherwise the coimand waits, 
giving a running list of run-unit user numbers accessing the schona as 
they are invoked and exit until all are finished. At this time the 
coimand is executed to conpletion. 



SECURITY 

Data Administrators 

Data Mministrators are identified by login name. Ihere exists a 
protected syston list of Data Administrator names, including a fixed 
nunber of privileged Data Administrators. A privileged Data 
Administrator need not specify privacy keys for schema privacy locks 
for ALTER, DISPLAY, and LOCKS. 

Schema Privacy Locks 

Privacy locks may be specified in the schema DDL for ALTER (ALLOCATE, 
CLEAR, DELETE, EXPAND, PACK, etc.), LOCKS (all commands with object KEY 
or KEYS) , and DISPLAY (VERIFY or implicit verification) . If locks 
exist for any of the above functions v*ien execution is attonpted, the 
user will be prompted for a privacy key for the related schema lock. 
If an invalid key is specified, the ccxnmand is aborted. Once a valid 
key is specified, the function ronains unlocked for the current schema 
until the next schema name (possibly the same) is specified in a 
coimand. 

COMMAM: SYNTAX 

Data ASministrator coimands are of the general form: 

verb object schema-name 

The coimiand verb must always be specified. If the command object is 
omitted, the object, SCHEMA, is assumed. When a conmand object 
specifies some part or function of a schema, the schema-name may be 
used to specify the desired schema. Once a schema has been specified 
by a schema-name on an appropriate command, the schema is the current 
schema until another schema-clause is specified. If the schema-name is 
emitted from a coiinand, the current sch^ia is assumed. The name of the 
current schema, if any, is displayed with each READY pronpt for a new 
command . 

The format of the schema-name is: 

OF SCHEMA schema-clause 

NOTE: 

The words OF and SCHEMA are not required. 



REV. 



IDB3043 DBA CCMMAND PFOCESSOR (DBACP) 



DBACP COMMAND VERBS AND OBJECTS 

■flie following are lists of valid caimand verbs and objects, itiose 
carmand words or word parts v*iich are not underlined may be omitted, 



VERBS 



ADD 

ADVANCE 

ALLOCATE 

ALLOW CONCU RRENT UPDATE 

CHANGE 

CLEAR 

DELETE 

DISALLOW OCMCU RRENT UPDATE 

EXPAND 

LOAD 

LOCK 

PACK 

guiT 

REMAKE 

RESTORE 

SAVE 

START 

STOP 

UNLOAD 

UNLOCK 

VERIFY 
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OBJECTS 

AFTER IMAGING 

AREA area-name 

AREAS 

BEFORE IMAGING 

CPUC OF RECORD recx)rd-name 

CALCS 

FILES 

KEY OF IDCK lock-name 

KEYS 

LIST ING * 

LOGGING 

SCHEMA schema-name * 

SCHEMftS * 

SET set-name 

SETS 

SUBS CHEMA subschema-name 

^JBSCHEWAS 

TAPE * 

* no schema-name with this object 
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COMMAND DESCRIPTIOSI 

The following is a description of each valid EBACP coranand grouped by 
cormand object and listed in alphabetical order. 
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* AFTER-IMAGING * 
***************** 



Function 

After- imaging is the process of writing two copies of a database block. 
When updating the database, the first copy is put into the database 
file; the second is written to a collector file v*iich contains 
after-images. After- imaging allows the database to be restored (roll 
forward) to its latest state in the event the files are destroyed. 

Format 

CLEAR 



^ START 
[ STOP 

'verify 



AFTER -IMAGIt^ [OF SCHEMA schema-name] 



Descriptions: 

CI£AR 

Delete all entries frcan after-image file and reinitialize. 

START 

Set a systan flag so that all run-units using this schema invoked after 
this point will save after-images in the after-image file for use with 
roll forward facilities. 

STOP 

Set a syston flag so that all run-units using this schema invoked after 
this point will not save after-images. 

VERIFY 

Display the volume name and entry number for the after-image file. 
Display a message stating if after- imaging is on or off. 
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******** 

* AREA * 
******** 

Function 

The object 'AREA' allows the Database Administrator to perform 
maintenance functions on an area such as restoration of files, file 
cleanup and packing, copying a file onto a magnetic tape or displaying 
information about the area file. 

Format 

LOAD 

PACK 

UNLOAD f AREA area-name [OF SCHEMA schema-name] 

VERIFY ] " 

Descriptions: 

LOAD 

Delete the dummy area file and restore the original area file from 
magnetic tape. 

PACK 

Erase all record occurrences in the area file that have been flagged as 
DELETED. Squeeze the occurrences and bucket directories as records are 
erased. After all deleted records are erased and their occurrences and 
directory entries are freed, all broken record occurrences (in more 
than one bucket) are examined and, if possible, concatenated in the 
newly freed spaces. The number of records erased and concatenated is 
displayed . 

NOTE: 

The before- image , after-image, and log files are 
automatically cleared by the PACK command since the images 
and log entries are no longer valid. 

WARNING: 

The "PACK AREA" command actually moves data in the area file, 
and will leave the file in an undefined state if aborted by 
user or operator intervention. It is therefore reccaimended 
that the schema be saved before one or more "PACK AREA" 
commands are executed. 



UNLOAD 

Copy the area file onto magnetic tape and replace the area file with a 
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dummy file containing information identifying the tape. 

VERIFY 

Display the following information about the area file: area name, 
number of buckets, and bucket size in bytes; volume name and entry 
number; login name, date, and time of creation; and percent empty, 
number of full buckets, and nunber of bytes free. If the area file has 
been unloaded, the date and time of unload are displayed instead of the 
usage statistics. 
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********* 

* AREAS * 
********* 

Function 

Area is a logical subdivision of a database. In Prime EBMS, Area also 
corresponds to a physical file on a disk. The object 'AREAS' allows 
the Database Administrator to list each area name and usage statistics. 

Format 

VERIFY AREAS [OF SCHEMA schotia-name] 

Descriptions: 

VERIFY 

Perform "VERIFY AREA area-name" for every area of the schema. 
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****************** 

* BEFORE-IMAGING * 
****************** 

Function 

Before- imaging is the process of making a copy of a database block 
before the block is updated. This allows the changes to a database to 
be cancelled (ROLL BACK) if an update to the iton was found to be in 
error. 

NOTE: 

The Prime TBfiS uses Before- Imaging Concurrent 
update protection. 

Format 

CLEAR 
START 

STOP (BEFORE IMAGING [OF SCHEMA schema-name] 
' VERIF Y! 

Descriptions: 

CIEAR 

Reinitialize all concurrent update and recovery information for the 
schema, including the log, before- image, and after-image files. 

START 

Set a system flag so that all run-units using this schema invoked after 
this point will save before- images in the before- image file for use 
with concurrent update and roll back facilities. 

STOP 

Set a systQti flag so that all run-units using this schema invoked after 
this point will not save befor e- images ; Before- imaging may not be 
stopped if concurrent update is currently allowed. 

VERIFY 

Display the size in bytes, volume name, and entry number of the befor e- 
image file. Display a message stating if be fore- imaging is on or off. 
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****************** 

* CAIiC OF RECORD * 
****************** 

Function 

CALC is a method of locating a record; where fields in the record are 
used as input to calculate the address of the record. CALC is one of 
three strategies used to locate records. The other two are direct and 

SET. 

ForiTBt 

LOAD 
I PACK 

UNLOAD I CALC OF RECORD record-name [OF SCHEMA schema-name] 
VERIFY 

Descriptions: 

LOAD 

Delete the dunmy calc file and restore the original calc file fron 
magnetic tape. 

PACK 

Rehash the CALC table, eliminating freed (deleted) entries, thus 
reducing the nunber of probes to failure or success. 

^JDTE: The before- image, after-image, and log files are automatically 
cleared by the PACK conmand since the images and log entries are no 
longer valid. 

NOTE: The "PACK CALC" ccranand generates a second file for the packed 
CALC table and deletes the old file after rehashing into the new one. 
There must be, therefore, enough space on the CALC file's volume for a 
temporary, duplicate file. 

UNLOAD 

Copy the CALC file onto magnetic tape and replace the CALC file within 
a diarmy file containing information identifying the tape. 

VERIFY 

Display the following information about the CALC file: record name and 
nunber of entries in the table; volume name and entry number; login 
name, date, and time of creation; and number of table entries empty, 
used, and freed. If the CALC file has been unloaded, the date and time 
of unload are displayed instead of the usage statistics. 
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********* 

* CALCS * 
********* 

Function 

The CALCS object of the verb 'VERIFY' locates every record with 
location mode CALC and displays each record name with various usage 
statistics. 

Format 

VERIFY CALCS [OF SCHEMA schema-name] 

Descriptions: 

VERIFY 

Perform "VERIFY CALC OF RECCBD record-name" for every record of the 
schema with location mode calc. 
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********* 

* FILES * 
********* 

Function 

FILES are the physical mapping of a database to the storage medium 
(DISK) . 

Ihe object 'FILES' allows all files within the named schema to be 
allocated, cleared, expanded, displayed or deleted. 

Format 

^ALLOCATE 



CLEAR 
' DELETE 
I EXPAND 

VERIFY 



, FILES [OF SCHEMA sct^ma-name] 



Descriptions: 

ALOXATE 

Estimate, allocate and initialize all area, set, and CALC files and the 
log, before- image, and after-image files for this schema. Estimation 
is an interactive process, requesting size information about various 
schema constructs, and displaying the estimated file sizes and 
characteristics. Allocation and initialization occur only after the 
user accepts the estimation given. Size information requested includes 
the following: maximum nimber of occurrences of each record type to be 
stored within each area; maximum nunber of occurrences of each record 
type to be inserted into all occurrences of sets in v^ich the records 
participate as manual mereibers; mean value of all items vAiich are used 
in variable occurs clauses; and the mean number of characters of itons 
of type variable length string. The allowable range of each of these 
requested figures is displayed if either an invalid answer or a null 
line (carriage return only) is entered. Using these figures, the 
following are calculated and displayed: for each area, the number of 
buckets and bucket size in bytes; for each non-singular set, the 
nunber of 10 byte directory entries (one per owner) ; for each member 
and search list type of a set, the monber or search list number, number 
of nodes and node size in bytes; for each record with location mode 
CALC, the nunber of 10 byte entries in the CALC table; for each record 
type, the nunber of data bytes and syston bytes (counts and pointers) 
for an "average" record occurrence; the total space used by all area, 
set, and CALC files in bytes; ar^ the ratio of data to total space for 
the maximum size database as a percentage. At this point the user may 
continue with allocation or abort the command. Information requested 
for file allocation includes a user estimate of the size of the 
before- image file as a percentage of total file space, and the name of 
each volume on vAiich the files should be allocated. A short 
verification (see VERIFY FILES) is displayed for each file after it is 
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initialized. 

CIEAR 

Verify and reinitialize all area, set, and CALC files and the log, 
before- image, and after-image files. Verification includes a full 
verify of each file (see VERIFY AREA, VERIFY SET, etc.) , after v*iich 
the user may continue with or abort the CI£AR canraand. Verification 
may be circumvented altogether ("DO YOU WISH TO VERIFY?") . A short 
verification (see VERIFY FILES) is displayed for each file before it is 
reinitialized. 

DELETE 

Verify and delete all area, set, and CALC files and the log, before- 
image, and after-image files. Verification proceeds as in the CLEAR 
FILES coimand. 

EXPAND 

Verify, examine, reestimate, and, if necessary, reallocate and expand 
all area, set, and CALC files. The log, before- image, and after-image 
files are reallocated and reinitialized. Verification proceeds as in 
the CLEAR FILES coimand. Reestimation is identical to the estimation 
process in the ALLOCATE FILES caimand with the following exceptions: 
reestimation takes in to account the current usage of each file by 
examining the amount of free space left, total amount of data stored, 
and various statistics on distribution of data within each file; 
instead of requesting "MAXIMUM NUMBER OF OCCURRENCES" of each record 
type within areas and inserted manually into sets, the request is for 
"MAXIMUM NUMBER OF AEDITICSSIAL OCCURRENCES", meaning additional 
occurrences to be stored and inserted from this point. Only those 
area, set, and CALC files v*iich need more space are reallocated and 
expanded. Otherwise, reallocation and expansion proceed as allocation 
and initialization in the ALLOCATE FILES ccsrinand, with the exception 
that the short verification is displayed for each file before it is 
expanded. NOTE: The "EXPAND" conmand generates a new file, 
initializes the new file, copies all data from the old file, and 
deletes the old file for each file to be expanded. There must be roan, 
therefore, for a new file to exist before the corresponding old file is 
deleted if the new file is to be on the same volume as the old file. 

VERIFY 

Display a short verification of all area, set, and CALC files and the 
log, before- image, and after-image files. If the files have not been 
allocated or have been deleted, short verification (as well as long 
verification) includes only the schema construct name and the message 
"<NOT ALLOCATED>". Otherwise, short verification includes the 
following: schema construct name; and the volume name and entry 
number. Verify of areas includes number of buckets and bucket size in 
bytes. Verify of CALC files includes the number of table entries. 
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*************** 

* KEY OF LOCK * 
*************** 

Function 

Those privacy clauses in the schema TDL using lock-names have no effect 
until a literal key is assigned. The object KEY allows the Data 
Administrator to assign, deallocate, change, and display the literal 
values for the keys for variable locks. 

Format 



ALLOCATE 



I CHANGE 

[ DELETE 

VERIFY 



KEY OF LOCK lock-name [OF SCHEMA schema-name] 



Descriptions: 

ALLOCATE 

Set the key for this lock if it is not set. 

CHANGE 

Verify and reset the key for this lock. 

DELETE 

Deallocate the key for this lock. 

VERIFY 

Display the key for this lock. 
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******** 

* KEYS * 
******** 



Function 

Like the object "KEY", KEYS allows the Data fiditiinistrator to assign, 
deallocate, change, and display the literal values for the keys for all 
variable locks for the schema. 

Format 

'allocate 



I CHANGE 
DELETE 
VERIFY 



KEYS [OF SCHEMA schema-name] 



Descriptions: 

ALLOCATE 

Set the keys for all variable locks in this schema that are not set. 

CHANGE 

Verify and reset the keys for all variable locks in this schema. 

DELETE 

Deallocate the keys for all variable locks in this schema. 

VERIFY 

Display the keys for all variable locks in this schema. 
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*********** 

* LISTING * 
*********** 

Function 

LISTING allows the IBACP to retain a recording of the session with the 
Database Administrator. The Database Administrator can save or clear 
the listing. 



Format 



( CLEAR ) LISTI NG 
( SAVE ) 



Descriptions: 

CLEAR 

Rewind and truncate the IBACP listing file DBA0nn, v^ere nn is the user 

nunber. Display and write out a heading including login name, terminal 

nunber, date, and time. When IBACP is invoked, a clear list is 
automatically performed. 

SAVE 

Copy the DBACP listing file into a user specified file. The DBACP 
listing includes a copy of all interactions between the user and DBACP 
except the values of keys of variable locks. 
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*********** 

* LOGGING * 
*********** 



Etinction 



>" 



The IBMS records all database transactions in a file called 'log file' 
The object 'LOGGING' and the four verbs allows the Database 
Administrator to control the operation of this log file. 

Format 

CLEAR 

START y LOGG ING [OF SCHEMA schema-name] 

STOP 

verify ! 

Descriptions: 

CIEAR 

Delete all entries frcm log file and reinitiate. 

START 

Set a systan flag so that all run-units using this schema invoked after 
this point will save all logging information in the log file. 

STOP 

Set a systan flag so that all run-units using this schema invoked after 
this point will not save logging information. 

VERIFY 

Display the volume name and entry nunber for the after-image file. 
Display a message stating if after-imaging is on or off. 
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********** 

* SCHOm * 
********** 



Function 



The object 'SCHEMA' allows the Database Administrator to perform 
maintenance functions on the named schema such as renaming, adding a 
new schema, deleting a schema, updating, etc. 



Format 



( ADD i 

I restore ! 

f ALLOW CONCU RRENT UPDATE 
DELETE 

DISALLOW CmOJRRENT UPDATE 
IDOK 
RENAME 
SAVE 
UNLOCK 
VERIFY 



[SCHEMA schema-name]* 



* If the Schema-name is omitted, the current schema is assumed. 

Descriptions: 

AH) 

Enter a schema which was created on another PRIME DBMS system into the 
Schema Directory for this system. The schema is assumed to have been 
transported intact from its original system on volumes on removable 
disk packs which have been loaded on this system. DBACP asks for the 
name of the volmie on #iich the schema table resides and the schema 
number from the original systan. If there are any conflicts with the 
schema name or number, the user may change the name or nimber of the 
schema being added or abort the cotimand. 

ALLOW CCNCURRENT UPDATE 

Set a system flag vAiich will allow concurrent updating and retrieving 
of all files for this schema for all run-units currently running and 
invoked after this point. Be fore- imaging must be on before concurrent 
update can be allowed. 

DELETE 

Verify and delete all subschemas, all area, set, and calc files, the 
log, before- image , and after-image files, and the schana table for this 
schema. Verification proceeds as in the CLEAR FILES COTmand with the 
addition of the schema table and the subschemas. When deletion is 
complete, the entry for the deleted schema is removed from the Schema 
Directory. 
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DISALLOW CCNCUPREOT UPDATE 

Set a syston flag v^ich will allow only one updating or multiple 
retrieving run-units to access the database concurrently. 

lcx:k 

Set a systsn flag vdiich prevents any run-units invoked after this point 
from accessing this schema. 

RENAME 

Change the name of this schema. If desired, the schema nunber may also 
be changed (syston supplied) . 

RESTORE 

Copy the schema and all of its related files frcan magnetic tape and 
enter it into the Schema Directory. If there are any schema name or 
number conflicts, the cotimand is aborted. 

SAVE 

Copy the schema and all of its related files onto magnetic tape. 

UNLOCK 

Set a syston flag vdiich allows run-units to access this schema after 
this point. 

VERIFY 

Display the following information about the schema table: schema name 
and nunber; volume name and entry number; login name, date, and time 
of creation; name of schema DDL source file; a message stating if 
concurrent update is allowed or not allowed; and messages stating if 
logging, before- imaging, and after-imaging are on or off. 
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*********** 

* SCHEJIAS * 
*********** 

Function 

The object 'SCHEMAS' allows the display of the names and nunbers of all 
SCHEMAS known to the DBMS. 

Format 

VERIFY SCHEMAS 

Descriptions: 

VERIFY 

Display the schema name and number of each schema in the syston. 
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ifk-klcicici: 

* SET * 
******* 



Function 



The object 'SET' allows the tetabase Administrator to perform 
maintenance functions on the SET file. 



Format 



imo 

UNLOAD 
VERIFY 



SET set-name [OF SCHEMA schema-name] 



Descriptions: 

DDAD 

Delete the duinny set file and restore the original set file fran 
magnetic tape. 

UNLOAD 

Copy the set file onto magretic tape and replace the set file with a 
dummy file containing information identifying the tape. 

VERIFY 

Display the following information about the set file: set name; 
volume name and entry number; login name, date, and time of creation; 
number of directory entries and number of entries free (for non- 
singular sets only) ; and for each member and search list, the member 
or search list number, number of nodes, node size in bytes, and nuitter 
of nodes free. 
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******** 

* SETS * 
******** 



Function 



The object 'SETS' allows each set name to be listed at the tenninal 
with various usage statistics. 

Format 

VEtUiFY SETS [OF SCHEMA schema-name] 

Descriptions: 

VERIFY 

Perform "VERIFY SET set-name" for every set of the schema. 
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************* 

* SUBSCHEMA * 
************* 

Function 

The 'SUBSCHEMA' object allows the Database Administrator to verify and 
delete the named subschema. 

Format 

(DELETE) 

(VERIFY) SUBSCHEMA subschona-name i;OF SCHEMA schema-name] 

Descriptions: 

DELETE 

Verify and delete the subschema. 

VERIFY 

Display the following information about the subschema table: subschema 
language type, name, and nunber; volume and entry number; login name, 
date, and time of creation; name of subschema EDL source file; and 
size of coimion work space in bytes for IML programs accessing this 
subschema . 
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************** 

* SUBSCHEMAS * 
************** 

Function 



This object performs the same functions as the 'SUBSCHEMA' object on 
all subschemas associated with the named schema. 

Format 

I DELETE) 

I VERIFY) SUBSC HEMAS [OF SCHEMA schema-name] 

Descriptions: 

DELETE 

Verify and delete all subschemas of this schema. The user may abort 
the conmand after the verification of any subschema. 

VERIFY 

Perform "VERIFY SUBSCHEMA subschema-name" for every subschema of this 
schema. 
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******** 

* TAPE * 
******** 



Function 



Ihe object TAPE allows the Database Administrator to control the 
magnetic tape such as rewind, advance tape forward, or to dii^lay 
information about the tape. 



Format 



ADVANCE 
CHANGE 



VERIFY 



TAPE 



NOTE: The first comnand executed vAiich accesses magnetic tape will 
request the tape unit number for that tape. All successive commands 
will assume the same tape unit until the E*Jysical end of tape marker is 
reached or a 'CHANGE TAPE' command is executed. 

Descriptions: 

ADVANCE 

Advance the tape forward to the next schema save or file unload and 
verify the header. 

CHANGE 

Rewind the tape and request a new tape unit nuiiber (may be the same) . 

VERIFY 

Read the tape header and display the following information: schema 
name and nimber; if file unload, name of schana construct; date and 
time saved or unloaded; and tape sequence nunber (always one for first 
tape and incremented by one for each successive tape for this schona 
save or file unload) . If the tape is positioned at the end of the last 
save or unload on the tape, the message "END OF TAPE" is displayed. 
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APPENDIX A 
PERFORMAICE NOTES 



The following presents a brief suimiary of performance-oriented 
considerations: 



1. The DBMS is designed for on-line processing and recovery. Itiis 
reflects in the generation approach to database update, and the 
delayed garbage collection of records. It is part of the 
rationale for using E-trees as the sole implementation of sets. 

2. Database Transactions (DBT's) provide for minimal data lockout 
and multiple concurrency (viz: retrieval and update) . 

3. TvK) levels of buffer - pooling create efficient physical I/O 
managonent and allow camion information to be shared. The large 
CPU page size and its equivalence to physical block size are a 
source of I/O speed. 

4. The databases are expandable, partly due to the plug-in 
expandability of Prime hardware, partly due to the ability of 
adjust for hardware expansion, and consumated in the EXPAND and 
PACK capabilities provided to the DBA by the Prime DBMS. 

5. The ability of the IBA to examine every aspect of the schema, and 
of the DBMS to utilize actual running figures is realized in 
Prime's DBMS. TBh estimates during later expansion are an aid to 
increasing overall efficiency. 

6. Rapid search is provided by several facilities: the hashing 
implonentation of CALC, the use of E-trees, and the Set Owner- 
Directory vi^iich associates owners with all their members, which 
is accessed directly fran every associated record occurrence 
(i.e., universal link to owner). 

7. Space utilization is generally efficient: the size of DBMS- 
structured files compares favorably with pre-DBMS versions. 

8. The hardware cache memory and randan-sectoring disk controller 
technique enhance speed; the self-correcting internal memory and 
disk controller enhance integrity; the hardware ring structure 
creates additional security. 
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MJ^XIMUMS 



APPENDIX B 
MAXIMUMS 



The following numbers are definitions of maximum sizes with respect to 
the DBMS. The reader should be aware that many of these numbers assume 
no storage limitation but is available for future syston expansion. 



PRIME Storage capability 

Maximum file size: 

Maximum Bucket size: 

Maximum Record Size: 

Maximum Number of Areas: 

Maximum Number of Pecord types: 

Maximum Number of Buckets per Area: 

Maximum Number of Pecord Entries per Bucket: 

Maximum Number of Items in a Record: 

Maximum Number of users: 

Maximum Number of concurrent files opened at the 

same time: 
Maximum Number of Sets: 
Maximun Mmber of Set Occurrences: 



2.4 Billion Bytes 
300 Million ^tes 
128,000 Bytes 
65,000 Bytes 
1023 Areas 
1023 record types 
( 2**20 )-l Buckets 

255 entries 
4096 items 
63 users 

256 files 
1023 Sets 
(2**27) 
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